벡터디비의 이해와 설계 — 딥다이브 학습 노트

채널: 뉴런데브 | 에피소드: 8개 | 대상: 7년차 Spring/Java 개발자 수준

학습 로드맵

EP1 정형/비정형 데이터 ──→ EP2 벡터화 기초 ──→ EP3 코사인 유사도
         │                        │                      │
         ▼                        ▼                      ▼
    데이터 본질 이해         Sparse vs Dense        L2 정규화 + 내적
         │                        │                      │
         └────────────────────────┼──────────────────────┘
                                  ▼
                        EP4 임베딩 평균의 가치
                                  │
              ┌───────────────────┼───────────────────┐
              ▼                   ▼                   ▼
      EP5 DB 선택          EP6 벡터 인덱스      EP7 실무 데이터
              │                   │                   │
              └───────────────────┼───────────────────┘
                                  ▼
                        EP8 임베딩 모델 진화

EP1. 정형 데이터와 비정형 데이터

핵심 요약

정형 데이터의 본질적 가치는 데이터 해석 엔트로피를 제거하는 것이다. 비정형 데이터는 해석 엔트로피가 높은 상태의 데이터이며, 정형/비정형은 이분법이 아니라 연속적인 스펙트럼이다.

딥다이브

데이터 해석 엔트로피

정형 데이터가 가치 있는 이유는 "누가 와도 동일하게 해석 가능"하기 때문이다. 스키마, 타입, 관계, 인덱스, 메타정보 등 여러 차원에서 사전 정의하여 해석의 여지를 제거한다.

해석 엔트로피 스펙트럼:

낮음 ◀━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ 높음
정규화된 RDB │ JSON(느슨한 스키마) │ 자유 텍스트
   ▲              ▲                    ▲
   │              │                    │
NULL 불허       필수키만 정의        구조 없음
FK 제약         검색 가능성만 보장   해석 무한대

핵심 통찰: NULL을 허용하는 순간 해석 엔트로피가 급등한다. 회원 이름이 NULL이면 — 이름이 없는 건지, 안 쓴 건지, 나중에 쓸 건지, 태명만 있는 건지 해석할 수 없다.

데이터 비용 체계

NoSQL의 본질: 느슨한 스키마

NoSQL은 "스키마가 없다"가 아니라 데이터 구조 스키마와 검색 가능성 스키마의 분리를 발견한 것이다.

// MongoDB: 데이터 구조는 자유, 검색 가능성은 최소 정의
{
  "name": "필수",        // 검색 가능성 스키마 (필수키)
  "email": "필수",
  "extra": { ... }       // 자유 구조 (데이터 스키마는 느슨)
}

비정형 데이터의 비즈니스 가치

벡터화 방법론 도입

비정형 데이터를 다차원 숫자 벡터로 표현하여 의미를 부여한다. 하나의 데이터("사과")에 다층적/다중적 의미(과일 vs 회사)를 여러 차원의 숫자로 표현한다. 역전파/그래디언트로 벡터 수치를 자동 산출하며, GPU 발전 이후 본격적으로 각광받기 시작했다.

실무 체크포인트

• [ ] RDB 설계 시 NULL 허용 여부를 해석 엔트로피 관점에서 재검토하고 있는가?
• [ ] MongoDB 사용 시 필수 키(검색 가능성 스키마)를 명시적으로 정의했는가?

EP2. 비정형 데이터를 벡터로 바꾸기

핵심 요약

벡터화의 두 가지 방식 — 희소 벡터(Sparse)와 밀집 벡터(Dense). Dense 벡터는 신경망으로만 생성 가능하며, 하나의 의미가 여러 차원에 분산 표현된다.

딥다이브

통계적 벡터화 vs 신경망 벡터화

Sparse vs Dense 벡터

Sparse 벡터 (희소):
[0, 0, 3.2, 0, 0, 0, 1.5, 0, 0, 0]  ← 일부 차원만 사용
 │  특성: 차원이 독립적, 개별 차원이 특정 의미를 가짐
 │  예시: BM25, TF-IDF, 풀텍스트 인덱싱
 └─ 비유: 바둑판에 돌이 몇 개만 올라가 있는 상태

Dense 벡터 (밀집):
[0.23, -0.15, 0.87, 0.44, -0.62, 0.31, ...]  ← 모든 차원 사용
 │  특성: 차원 간 상호작용, 개별 차원에 독립적 의미 없음
 │  생성: 신경망(편미분/그래디언트/손실함수)으로만 가능
 └─ 비유: 금속 큐브 — 분자 밀도가 높아서 단단함

MoE와 Dense/Sparse 모델

멀티모달 임베딩 시대

"텍스트끼리만 임베딩해서 RAG"은 2022년 사고방식이다. 현재는 멀티모달 임베딩이 주류다.

실무 체크포인트

• [ ] BM25(Sparse)와 임베딩(Dense)의 차이를 이해하고 하이브리드 전략을 수립했는가?
• [ ] 프로젝트에서 텍스트 외 모달리티(이미지, 코드 등)의 임베딩 필요성을 검토했는가?

EP3. 임베딩 모델과 코사인 유사도

핵심 요약

코사인 유사도는 두 벡터 간 각도의 유사성을 측정한다. L2 정규화된 벡터에서는 내적 = 코사인 유사도가 되어 연산이 극도로 단순해진다. 임베딩 모델은 앵커-포지티브-네거티브 트리플릿과 코사인 유사도 손실 함수로 학습한다.

딥다이브

L2 노름과 정규화

L2 노름 (벡터 크기):
  ‖v‖ = √(v₁² + v₂² + ... + vₙ²)    ← 피타고라스 정리의 n차원 확장

L2 정규화:
  v_norm = v / ‖v‖                    ← 각 원소를 노름으로 나눔
  결과: ‖v_norm‖ = 1                  ← 노름이 항상 1

증명: Σ(vᵢ/‖v‖)² = Σvᵢ²/‖v‖² = ‖v‖²/‖v‖² = 1

코사인 유사도 공식과 단순화

일반 공식:  cos(A, B) = (A · B) / (‖A‖ × ‖B‖)

정규화 후:  ‖A‖ = ‖B‖ = 1 이므로
            cos(A, B) = A · B  (내적 = 유사도)

구현: 루프 1번 — 같은 인덱스 원소끼리 곱해서 합산하면 끝

코사인 유사도 계산 예시: | 벡터 A | 벡터 B | 유사도 | 각도 | 해석 | |--------|--------|--------|------|------| | [0.6, 0.8] | [0.8, 0.6] | 0.96 | ~16° | 매우 유사 | | [0.6, 0.8] | [0.6, -0.8] | -0.28 | ~106° | 비유사 |

임베딩 모델 학습 원리

[앵커] "강아지가 공을 쫓는다"
   │
   ├── [포지티브] "개가 장난감을 따라간다"     → 유사도 높게 학습
   │
   └── [네거티브] "오늘 주식 시장이 폭락했다"  → 유사도 낮게 학습

손실 함수: 코사인 유사도 기반
역전파: 손실 결과에 따라 벡터값 조정
반복: 수억 건 데이터에 대해 → 시멘틱 벡터 완성

유사도 측정 방법 비교

코사인 유사도가 표준인 이유: 특정 분야(정치 등) 데이터가 많으면 해당 벡터 크기가 커져 유클리드/내적이 왜곡된다. 코사인 유사도는 각도만 비교하므로 이 문제가 없다.

실무 체크포인트

• [ ] 벡터 DB에서 유사도 메트릭을 코사인 유사도로 설정했는가?
• [ ] 임베딩 벡터가 L2 정규화되어 저장되는지 확인했는가?

EP4. 임베딩 평균의 가치

핵심 요약

여러 벡터의 산술 평균(Mean 벡터)은 수학적으로 유의미하다. 내적의 분배 법칙, 고차원 직교성, 국소적 선형성이 그 근거이며, 추천 시스템을 ML 없이 산술 연산만으로 구현할 수 있다.

딥다이브

Mean 벡터가 의미 있는 수학적 근거 3가지

(1) 내적의 분배 법칙 (가장 핵심)

dot(mean(a, b), q) = (dot(a, q) + dot(b, q)) / 2

→ a가 q와 유사하고 b도 q와 유사하면, mean(a,b)도 q와 유사
→ 내적(유사도)에 선형성이 성립

(2) 고차원 직교성 - 500~600차원 이상에서 임의의 두 벡터는 확률적으로 거의 직교 - 직교하는 벡터를 평균내면 고유한 방향(의미)이 생김 - 저차원(2D, 3D)에서의 직관과 다름 — 고차원일수록 잘 동작

(3) 국소적 선형성 - 지구는 둥글지만 운동장은 편편함 → 국소적으로 선형 근사 가능 - 다차원 벡터 공간도 마찬가지로 국소 영역에서 산술 평균 유효

Mean 벡터의 단점: 희석(Dilution)

좋아하는 것 A (유사도 +0.9)  ─┐
                               ├→ 평균 유사도 ≈ 0.3 (중립으로 희석)
싫어하는 것 B (유사도 -0.3)  ─┘

→ 상반된 속성이 평균으로 제거됨
→ 해결: 가중 평균, 클러스터링 후 개별 Mean 등

실용 예시: 산술 평균 기반 추천

1. 내가 구매한 5개 상품의 임베딩 벡터를 산술 평균
   mean_vec = (item1 + item2 + item3 + item4 + item5) / 5

2. mean_vec와 전체 상품 벡터의 코사인 유사도 계산

3. 유사도 높은 순으로 = 추천 상품
   → LLM 없이, ML 없이, 산술 연산만으로 추천 시스템 구현

벡터 연산 확장

실무 체크포인트

• [ ] 추천 시스템에서 복잡한 ML 모델 전에 Mean 벡터 베이스라인을 먼저 시도했는가?
• [ ] Mean 벡터의 희석 문제를 인지하고 상반 속성을 분리하는 전략을 검토했는가?

EP5. 임베딩용 DB 선택

핵심 요약

벡터 DB 선택은 기존 DB 확장 vs 벡터 전용 DB의 두 갈래다. 기존 DB 확장은 하이브리드 검색이 강력하고, 전용 DB는 벡터 최적화와 GPU 활용이 장점이다.

딥다이브

기존 DB에 벡터 필드 추가

기존 DB 확장 vs 벡터 전용 DB

⚠️ 최신 업데이트: 벡터 DB 벤치마크 (2026)

pgvectorscale이 Qdrant 대비 11.4배 높은 QPS를 기록했으나, 1억 벡터 이상에서는 전용 DB의 확장성이 유리하다.

하이브리드 검색의 필요성

"고양이가 장난감을 물어왔다" vs "개가 장난감을 물어왔다" — 벡터 유사도는 높지만 사용자는 불만족. 키워드 검색(BM25) 병행이 검색 품질을 높인다.

실무 전략:
1. SQL JOIN으로 데이터셋 축소 (메타데이터 필터링)
2. BM25 키워드 매칭
3. 벡터 유사도 검색
4. 결과 머지 → 리랭킹

실무 체크포인트

• [ ] 기존 PostgreSQL/Oracle이 있다면 벡터 필드 추가를 먼저 검토했는가?
• [ ] 벡터 전용 DB 도입 시 메타데이터 필터링과 BM25 대안을 확보했는가?
• [ ] 검색 품질을 위해 하이브리드 전략(키워드 + 벡터)을 수립했는가?

EP6. 벡터DB에도 인덱스가 존재함

핵심 요약

밀집 벡터는 정렬이 불가능하므로 B+트리를 적용할 수 없다. 대신 HNSW(Hierarchical Navigable Small World) 가 벡터 인덱싱의 사실상 표준이다. IVF, PQ 등 보조 기법도 있지만 HNSW가 대세다.

딥다이브

B+트리가 벡터에 안 되는 이유

B+트리 전제: 데이터가 정렬 가능해야 함
  - 정수: 1 < 2 < 3 ✓
  - 문자열: "A" < "B" < "C" ✓
  - 밀집 벡터: [0.23, -0.15, 0.87] vs [0.44, 0.31, -0.62] → 정렬 불가 ✗

→ 코사인 유사도는 쌍별(pair-wise) 비교만 가능, 전체 순서화 불가
→ 유클리드 거리의 군집 분포가 코사인 유사도 군집과 어느 정도 유사한 성질을 활용

IVF (Inverted File Index)

100개 벡터 중 대표 벡터 10개 선정 (k-means 등)

쿼리 Q → 대표 벡터 10개와 비교 → 가장 유사한 그룹 선택 → 그룹 내 상세 검색

장점: 검색 범위를 1/10로 축소
단점: 대표 벡터 경계에 있는 벡터를 놓칠 수 있음

PQ (Product Quantization)

500차원 벡터 → 10~20차원으로 양자화(축소)

1차: 축소 벡터로 후보 추림 (빠르지만 부정확)
2차: 원본 벡터로 정밀 비교 (정확하지만 느림)

장점: 메모리 절약, 빠른 1차 필터링
단점: 양자화 손실로 recall 감소

NSW (Navigable Small World) 동작 원리

그래프 구축:
A(엔트런스) 등록 → B 등록(A와 연결) → C 등록 시:
  A까지 거리 = 15, B까지 거리 = 5
  → C는 B의 "친구"로 등록 (B가 A를 스크린)

탐색:
Q(쿼리) → A(엔트런스, 거리 20) 시작
  → A의 친구 B(거리 10), D(거리 22) 중 B 선택
  → B의 친구 C(거리 7), F(거리 12) 중 C 선택
  → C의 친구 중 더 가까운 게 없으면 C가 최종 결과

HNSW: NSW의 다계층 확장

Layer 3 (최상위): 노드 수 적음, 넓은 범위 탐색
    ↓ 가장 가까운 노드에서 하위 레이어로
Layer 2: 노드 수 중간
    ↓
Layer 1: 노드 수 많음
    ↓
Layer 0 (최하위): 모든 노드 포함, 정밀 탐색

→ 상위에서 대략적 위치 파악 → 하위에서 정밀 탐색
→ 로그 수준 탐색 복잡도 달성

⚠️ 최신 업데이트: GPU 가속 HNSW (2025-2026)

NVIDIA cuVS를 활용한 GPU 가속 HNSW 인덱싱이 등장했다: - 인덱싱 처리량 12배 향상 - Force-merge 레이턴시 7배 감소 - Elasticsearch가 cuvs-java를 통해 cuVS 통합

인덱스 한계 인식

HNSW 인덱스는 근사 최근접 이웃(ANN)이므로 코사인 유사도 최상위 결과가 빠질 수 있다. 데이터 특성에 따라 인덱스 성능이 달라지므로 반드시 벤치마크 평가가 필요하다.

실무 체크포인트

• [ ] HNSW 파라미터(efConstruction, M)를 데이터 규모에 맞게 튜닝했는가?
• [ ] 인덱스의 ANN 특성으로 인한 recall 손실을 측정했는가?
• [ ] 벡터 스키마 설계 — 어떤 데이터를 어떤 테이블/컬렉션으로 분리할지 결정했는가?

EP7. 벡터 DB용 실무 데이터 특징

핵심 요약

벡터 DB 프로젝트의 핵심은 DB 자체가 아니라 비정형 데이터의 정제다. 청킹이 검색 품질의 80% 이상을 좌우하며, 메타데이터 보강과 보안 정책이 실무의 난관이다.

딥다이브

기업의 벡터 DB 타겟 데이터

정형 데이터 (RDB)          비정형 데이터 (벡터 DB 타겟)
━━━━━━━━━━━━━━━━         ━━━━━━━━━━━━━━━━━━━━━━━
회원, 주문, 결제           노션, 슬랙, 메신저 로그
재고, 배송                 PPT, PDF, 엑셀
계약, 인사                 공유 폴더 문서
                           회의록, 메모, 이메일
↑ 핵심 비즈니스 데이터      ↑ 사소하지만 방대한 데이터
↑ 일관된 보안/접근 정책     ↑ 권한 구조가 엉망

데이터 정제 파이프라인

[원본 데이터] → 변환/파싱 → 청킹 → 메타데이터 보강 → 스키마 설계 → 벡터 DB
                  │          │           │                │
                  ▼          ▼           ▼                ▼
            PDF→텍스트   의미 단위로   시간, 출처,      컬렉션 구조
            PPT→마크다운  레코드 분리  권한, 분류ID     테이블 분리
            엑셀→HTML    (80%+ 영향)  키워드 태그       세션별 분리

청킹이 80%를 좌우하는 이유

나쁜 청킹: 고정 길이로 자르기

"오늘 회의에서 프로젝트 A의 일정을 | 논의했습니다. 결론은 다음과 같습니다..."
                                    ↑ 의미가 잘림

좋은 청킹: 도메인 이해 기반

메신저 대화 → 같은 기사끼리, 같은 날짜끼리 묶기
PPT → 슬라이드 1장 = 1레코드? 3장 = 1레코드? → 도메인에 따라 판단
코드 → 함수/클래스 단위로 분리

메타데이터 보강

임베딩 유사도만으로는 부족하다. 정형적 필터링을 위한 메타데이터가 검색 품질을 결정한다.

데이터 정제 3단계 진화

실무 팁: PDF 직접 파서를 만들지 말고 AI(Gemini, Grok 등)에 던져서 파싱하는 것이 훨씬 효율적이다. 엑셀도 GPT에 던져서 HTML로 변환하는 편이 낫다.

실무 체크포인트

• [ ] 청킹 전략을 도메인에 맞게 설계했는가? (고정 길이가 아닌 의미 단위)
• [ ] 메타데이터 스키마를 사전에 정의했는가? (시간, 출처, 권한, 분류ID, 키워드)
• [ ] 비정형 데이터의 보안/접근 권한을 청크 수준에서 관리하고 있는가?

EP8. 임베딩용 모델에 대해

핵심 요약

임베딩 모델은 벡터 손실학습 → 인코더(BERT) → 디코더(LLM) 기반으로 진화했다. 하드 네거티브 마이닝, 인배치 네거티브로 학습 품질을 높이고, MRL(Matryoshka Representation Learning)로 벡터 차원을 유연하게 축소할 수 있다.

딥다이브

학습 데이터 문제와 해결

(1) 긍정셋 문제: 하나의 앵커에 여러 긍정셋이 존재하며 중요도가 다름 → 가중치 부여 필요

(2) 부정셋 문제: 범위가 무한함

앵커: "오늘은 매우 추운 날씨였습니다"

부정셋 예시:
  ├── "오늘은 매우 따뜻한 날씨입니다"  ← 미묘한 차이 (Hard Negative)
  └── "나는 오늘 밥을 먹었습니다"      ← 완전 무관 (Random Negative)

→ Random Negative만으로는 학습 비효율적

해결책:

모델 아키텍처 진화

1세대: 벡터 손실학습 모델 (Word2Vec 등)
  │  한계: "후졌다" — 의미 표현력 부족
  ▼
2세대: 인코더 기반 (BERT, Sentence-BERT)
  │  특징: 양방향 어텐션, Mean Pooling으로 벡터 추출
  │  규모: M 단위 (110M ~ 700M 파라미터)
  ▼
3세대: 디코더 기반 (LLM 파인튜닝)
  │  특징: 인스트럭션 학습, 마지막 토큰(EOF)으로 벡터 추출
  │  규모: B 단위 (7B ~ 8B 파라미터)
  │  장점: 큰 청크 처리, 컨텍스트 지정 가능
  ▼
NVIDIA NV-Embed V2: LLP 레이어 추가
  │  EOF만 쓰는 한계 극복, 모든 토큰 정보 반영
  └─ MTEB 리더보드 상위권

인코더 vs 디코더의 벡터 추출

인스트럭션 기반 임베딩

# 디코더 기반 모델은 프롬프트로 임베딩 컨텍스트 지정 가능
embedding = model.encode(
    "이 대화는 소설 관련입니다: 해리가 지팡이를 들었다",
    instruction="소설 및 문학 컨텍스트에서 임베딩"
)
# vs
embedding = model.encode(
    "이 대화는 비즈니스 관련입니다: 해리가 지팡이를 들었다",
    instruction="비즈니스 컨텍스트에서 임베딩"
)
# → 같은 텍스트라도 인스트럭션에 따라 다른 벡터 생성

MRL (Matryoshka Representation Learning)

학습 시: 다중 차원으로 동시 학습
  1000차원 손실 + 500차원 손실 + 200차원 손실 + 100차원 손실 + 50차원 손실
  → 앞쪽 차원에 중요 정보가 집중되도록 학습

사용 시: 벡터 앞부분만 잘라도 의미 보존
  [d₁, d₂, ..., d₂₅₆, d₂₅₇, ..., d₃₀₇₂]
   ├──── 앞 256차원만 사용 ────┤
   └─ 원본 대비 96% 성능 유지 (OpenAI text-embedding-3 기준)
       저장공간 92% 절약, 인덱싱 비용 대폭 절감

비유: 러시안 인형(마트료시카) — 까면 또 나오고, 까면 또 나옴

⚠️ 최신 업데이트: 임베딩 모델 현황 (2025-2026)

⚠️ 최신 동향: MRL의 짧은 차원에서 성능 저하 문제를 보완하기 위해 Sparse Coding 기반 적응형 표현 연구가 진행 중이다. MRL은 표준으로 정착했으나, 극단적 축소(50차원 이하)에서는 대안 탐색이 필요하다.

실무 체크포인트

• [ ] 임베딩 모델 선택 시 MTEB 리더보드를 참고하고 도메인에 맞는 모델을 벤치마크했는가?
• [ ] MRL 지원 모델을 사용하여 인덱싱용 축소 벡터와 리랭킹용 원본 벡터를 분리 운영하는가?
• [ ] 디코더 기반 모델의 인스트럭션 기능을 활용하여 도메인 컨텍스트를 지정했는가?

부록 A. 용어 사전

부록 B. 비교표 모음

B-1. 유사도 측정 방법

B-2. 임베딩 모델 아키텍처

B-3. 벡터 인덱스 비교

부록 C. 참고 링크

• MTEB Leaderboard — 임베딩 모델 벤치마크
• HNSW 원리 (Pinecone) — HNSW 상세 설명
• MRL 논문 — Matryoshka Representation Learning 원본 논문
• pgvector — PostgreSQL 벡터 확장
• ChromaDB — 경량 벡터 DB
• Qdrant — 오픈소스 벡터 전용 DB
• NV-Embed V2 (NVIDIA) — NVIDIA 임베딩 모델
• NVIDIA cuVS GPU 가속 — GPU 가속 HNSW 인덱싱